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COPYRIGHT NOTICE 

A portion of the disclcsxire of this patent apphcation contains material which is subject 
to copyright protection. The copyri^t owner has no objection to the facsimile reproduction by 
anyone of the psA&at document or patent disclosure as it appears in the Patent and Trademark 
OfTice patent files or records, but othea-wise reserves all copyright rigjits v^tsoev®-. 

CROSS REFERENCE TO RELATED APPLICATION 

This application claims the benefit of prior filed co-paiding Provisional Application No. 
60/270,370 filed on Feb. 20, 2001 entitled "METHOD AND APPARATUS FOR A 
PROFESSIONAL PRACTICE APPLICATION" which is incorporated herein by reference in 
its aitir^ as if fiilly set forth herein. 

BACKGROUND OF THE INVENTION 

1. Field of Invention 

This invaition relates generally to a web application for a professional practice and more 
particularly, to methods and apparatus for managing application usage. 

2. Description of the Related Art 

Service professionals such as: accountants, doctors, entertainers, lawyers, 
consultants, brokers, ardiitects, etc. require professional practice applications to help 
organize their business. Traditionally these software apphcations are sold in modular form 
on a stand alone or networked basis. A professional might buy a first apphcation for 
tracking clients/customers/patients and their matters/cases/histories. Another application 
would handle time keeping. Still another application would handle calendaring or 
docketing of key events. Other applications would handle accounting functions such as: 
accounts receivable, accounts payable, payroll, general ledger and journal. 



Traditionally, the use of each module, e.g. case management, time keeping, 
docketing, accounting, was limited to sela;ted members of the firm or sa^ce business 
depending on Iheir role in the organization. Thus, the bookke^er for a givai service 
profession would be the only within the organization with access to the accounting 
software application. Attorneys, or doctors for example would be givai access to the time- 
keeping application, but not their staff A docket clerk would be in control of a 
docketing/calaidaring application and so forth. As employees of each sa-vice business are 
hired they are given access to the appropriate application(s) by means of loading the 
application on their computer, with or without a password. When an employee leaves a 
service business they no longer have access to the computer on which their application v^s 
loaded. 

Recently, several of the above named applications, e.g. time keeping and billing 
have been offered on the Intemet. Typically these are offered to single users on a 
subscription basis. While such offerings may be of use to sole practitioners, they do not 
meet the needs of larger service profusion businesses because they are not set up for 
service professionals operating in a groiq). 

What is needed is a professional service application suitable for use over the Intemet by 
individual service professionals or service professionals operating in groups. 



SUMMARY OF THE INVENTION 

The current invention provide method and apparatus for managing a professional 
practice application over tiie Intemet or other wide area network (WAN) or local area 
network (LAN). The appUcation includes a range of integrated feature: for tradcing 
clioits/customors/patimts and their matt€rs/cas««/histories; for time keeping and billing; 
for docketing/'calendaring of key events; and for accounting. The appUcation is accessible 
to individual or ^oi;^ users, with each group able to customize the applicatioti views that 
are presented to each user of a group depraiding on the role assigned to each individual user 
by a manager within ^ch group. 

In an embodiment of the invaition a professional practice application configxjred for 
use over a network 1^ usqts operating professionally as individuals or as one or more 
groups is provided. The appUcation includes: a database, wdo pages, and an access 



controller. The database includes portions for selectively receiving and supplying data 
related to a professional practice. The web pages include a set of web pages for viewing 
and entering data rdated to professional practice into said database, and at least one 
managerial web page for entering ofaccess roles for each usa-. The access controUa: 
5 controls access by each uss" to selected ones of both said web pages and said plurality of 
portions of said database with access roles vdiich match the access role of the user. The 
access controller supplies the at least one managerial weto page to each user with an access 
role of manager to vary access privileges to the professional practice application for other 
users within the corresponding manager's group. 
10 BRIEF DESCRIPTION OF THE DRAWINGS 

Th^e and other features and advantages of the present invention will become more 
apparent to those skilled in the art from the following detailed description in conjunction with 
the appended drawings in vAiich: 

FIG. 1 is an overall system diagram of an individual and groiq) users connect^ over 
1 5 the Internet to a professional practice applicatioa 

FIG. 2 is a hardware block diagram of a computer suitable for delivering the 
professional practice management application shown in FIG. 1. 

FIGS. 3 A-D show various graphical user interfaces for signup and nmnagement of the 
practice nmnagement application by each individual user and/or group of users. 
20 FIG. 4 shows system level data structures associated with the delivery of the practice 

managemait application to various users within each group. 

FIGS. 5A-C show various embodimoits of software modules and management tables 
for the professional practice application of the current inventioa 

FIG. 6 is a process flow diagram of Ihe processes implemented by the application 
25 server shown in FIG. 1 for management of individual and group use of the professional 
practice application. 

DETAILED DESCRIPTION OF THE EMBODIMENTS 

FIG. 1 is an overall system diagram of an individual and group users connected 
30 over tiie Internet to a professional practice application. The appUcation includes a range of 
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integrated features: for tracking clients/customers/patiaits and their matters/cases/histories; 
for time keeping and billing; for docketing/calaidaring of key events; and for accounting. 
The application is acc^sible to individual or group users, with ^h group able to 
customize the application views that are presaited to eadi user of a group depending on the 
role assigned to each individual user by a manager within each group. 

In FIG. 1 three groups are shown connected over the Internet 120 to the web site 
from vdiich the professional practice appHcation 140 is delivered. The first "group" is a 
sole practitioner 146 w4io operates her own law firm She is given the role of manager and 
is thus able to use all features of the application and in addition to add other users to her 
firm as it grows. The second group is law firm "A" , its client "B" and their accountant 
1 18. The law firm "A" includes docket cla-k 1 14, secretary 1 12, manager 144 and attorney 
partaer 110. These users are all coupled to one another via local area network (LAN) 116 
and througji the LAN via the Itrtemet 120 to the server 122. Their client "B" includes an 
invfflitor 106 and an intellectual property (IP) manage- 104, coupled to one another via 
LAN 108, vMch in turn coiq)les to the Intemet 120. Within this second group, the user 
with a managerial role, i.e. manager 144, of the law firm controls the profrasional 
application views \sdiich are presented to employees within the firm as well as the otho" 
users defined as part of the group vAio are not part of the firm, eg. the client "B" and the 
accountant 118. The third group is law firm "C" and their accountant 118. Law firm "C" 
includes employee members: attomey/partner 100 and a user 142 with the role of manager. 
The members of this firm are coupled to one another via LAN 102, and via the Intantiet to 
the accountant 118 and the web application 140. 

Each of these users accesses the professional practice applicatitai 140 over the 
Intemet 120 or other wide area network (WAN) or local area network (LAN). The 
application is provided on serva- 122 and associated storage device 124. The storage 
device includes various web pages 134 and data tables 126 associated with the application. 
A registration table 128 is part of the application and allows the user within each group to 
set up new users and allocate roles to users over the Intemet. Access tables 130-132 
correlate each web page 134 and data table 126 with a specific user role. 

FIG. 2 is a hardware block diagram of a computer suitable for delivering the 
professional practice management application shown in FIG. 1. The server 122 includes at 
least one processor 204 for processing information. The processor couples via a bus 200 with 
Input/Output (I/O) devices 206, network device 208, main and read only memories 210-212 



and mass storage device 214. The I/O device 206 may include keyboard and display. The 
network device 208, wired or wirel^s, couples the server with the internet 120, or other wide 
area network (WAN) or local area network (LAN). The main memory 210 stores information 
and instructions for the proc^sor. The r^d only memory 212 stores static information and 
boot instructions for the server. Tlie mass storage device 214, such as magnetic disk and 
associated disk drive, couples with the bus 200 for storing information and instructions on the 
storage medium 124. 

FIGS. 3 A-D show various graphical user interfaces for signup and management of 
the practice management application by eadi individual user and/or group of users. FIG. 
3 A shows a browser into-face 300 in v^ch the home page 304 of the application is shown. 
The browser interface includes a maiu bar 314, an address bar 316, window management 
icons 302 and the display area in vMch the home page 304 is displayed The home page 
304 includes user interfaces 330 and 332 for selecting a feature of the appHcation. 

FIG. 3B shows a user r^stratioai window 306. In an embodiment of the invention 
tiie veer is directed to this window upon selection of dther of the features on the home page 
if they have not logged in. The user registration window includes fields for user name and 
password 340 and 342 r^pectively. After entry of user name and password a user may 
login with user icon 344 and begin viewing the application. Alternately, vAi&Q the user has 
a role of manager they may select usa- icon 346 to log in as manager in vitech event they 
will be presaited with a user interface such as that shown in FIG. 3D. Where the user is 
not yet registered they vwU select registration icon 348 and will be presented with the user 
interface shown in FIG. 3C. 

FIG. 3C shov^^ the registration page 308. That page includes fields for recording group 
identifier 362, user ID 364, password 366 and role 368. All new users not registered by a 
manager as part of an existing group be automatically given the role of manager as shown 
in FIG. 368. This role allows them full access to the appUcation in general and to the manager 
interface shown in FIG. 3D. This latter interface allo\^^ them to add or remove users from 
their group and to allocate roles to the user. Additional fields 370-374 are provided for 
contact, billing and group information respectively. A user icon 376 is provided for 
submitting the entered data 

FIG. 3D shows the browse" with the managerial intoface. Hiat into-face is a firame 
with an upper form portion 310 for adding new users, for viewing existing users, and for 



updating/deleting users of the group. The upper form includes fields for group ID 362, user ID 
364, password 366 and role 368. Since a managerial role only exists for users with established 
groups tile group ED is a read only field and can not be altered. Rol^ are sdected from a drop 
down list 368 or other suitable interface In the exan^le shown roles include manager, 
attorney, secretary, docket clerk, accounting, and chant. As will be described in greater detail 
in the following drawings these roles and the operation of 1he apphcation responsive to fee 
selection thereof govern the viewing and use of the application for each associated user. 
Additional fields 370-374 for entering contact, billing, and group information respectively may 
also be provided. Icons 380-384 for respectively: deleting, updating, and adding a user to a 
group are shown. Processes discussed in greater detail in the following FIG. 6 assure that at 
least one individual in each group retains the role of manager thus assuring that Ihe managerial 
interface and the capabilities it provides will remain available for tiie group. 

FIG. 4 shows system level data structures associated with the ddivery of the practice 
management application to various usars within each group. The apphcation data tables 126, 
registration tables 128, access tables 130-132, web pages 134 are shown as accessed by the 
combined web server 400 and database server 402. These latto" software modules are part of 
the server 122 (See FIG. 1). The web server such as Jrun ® by Allaire Corporation and the 
database engine such as Oracle 8i® by Oracle Corporation handle the Internet communication 
together with application logic and the database I/O r^pectively for the professional practice 
application. The apphcation tables 126 include billing table 412, group table 410, client table 
414, matta- table 416, time/cost table 418, docket/action table 420 and invoice table 422. 
These tables are configured as a relational database. Other database formats, i.e. flat file, and 
object based may also be used in the practice of ttie inventioa The registration table 128 
contains the group identifiers and within each group ihe user names, passwords and roles. The 
access tables contain for each wdb page and each table the associated role(s) with which the 
table or page correlates. 

Web pages 134 define the application interfaces) for the users to the application. 
Selected ones of the pages are dynamically configurable depending on the associated role of 
tiie user viewing the page These pages, eg. "...jsp" pages are assembled by the web server on 
the basis of tiie role of flie requestmg user. The role of the requesting user is determined 
during session setup using the user ID and password and the corresponding role of the vis&r as 
maintained in the registration table 128. The web server controls presentmait of the page and 



of djmamicaliy interpreted elements within a page based on the role of the user. In the 
example shown tiie user has requested 450 a time/costjsp page 432j from the home page 304 
(See FIG. 3 A) or other page in the application. The requested page has one or more roles 
associated with it vyiiich are stored in the page access table 130. Assuming the users role 

5 correlates with the role(s) in the page access table the page is assembled for presaitment to the 
user. The form in v^ch Uie page is presented will vary between users vAere as here there are 
dynamically interpreted elements within the page. In the example shown the .jsp page 432j 
will be assembled into at least three distinctive TC.HTM pages in a markup language 
depaiding on the role of the user and the roie(s) associated with each dynamic element within 

10 Ihe page. In the example shown the jsp page includes a static portion 438 in hypertext 

(HTML) or other markup language (HTML) as well as ^mamic portions. Dynamic portions 
434, 436, 440 and 442 are shown Dynamic portion 434 is a string which invokes the web 
server to determine the role of the requesting user. Dynamic portions 436, 442 are a database 
query and listing of query results to one or more of the database tables 126, the results of 

15 yMch vary depending on the role of the requesting usa*. I^namic portion 440 conditions flie 
assembly by the web server of a user interface such as a button, input box, text field, etc. on 
the role of the user. 

Three separate assembly paths 452abc brought about by the dynamic elements within 
the page result in the display of three distinct pages 432a, 432b, 432c. Page 432b is 

20 assembled by the web server 400 in response to a request from a user with a role of secretary 
for the tima'cost.jsp page. That page 432b includes a list 462 with individual records 
displayed, e.g. record 472. In the exanple shown this is a time/cost Ust for the attorney with 
y^om the secretary is showing the attorney's time entries for the particular matter recorded in 
the link fields 470. The page contains no active elements, e.g. buttons, or uniform resource 

25 locators (URLs). 

Page 432c is assembled by the web server 400 in response to a request from a user with 
a role of accountant for the time/'cost.jsp page. Hiat page 432c includes a list 464 with 
individual records displayed, e.g. record 472. The records in this list include tima'cost records, 
e.g. record 474, for all attomeys who billed on the associated matter shown in link fields 470. 

30 The nature and scope of the query may be determined by the role of the requesting user. 
Additionally, eadi record has an associated URL represented by the underlining of all or a 
portion of tiie record. This active link, is injected to the *.HTM page 432c during its assembly 
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from the associated jsp page 432j by the web server based on the role of the user requesting the 
page The selection of the active link results in anotiier page request to the web server for a 
related time-cost-fonn.jsp page (not shown). The web server processes flie request in the 
manner discussed above, checking the role of the page vs. the role of the user in the 
registration table, and assembling any dynamic elements also to accord with the user. The 
assembled time-cost-formhtm page 480c is shown with hnk fields 482 and form 484 which 
displays the details of the selected record. No editing or updating icon elements are available 
to the user with role of accountant. 

TTie third of tilie assembled TChtm pages 432a contains all tihie features of the page 
assembled for the accountant plus an active element 468 for mtermg a new time/cost entry. 
The page includes a list 460 with individual records, e.g. record 466, each of \n*iich includes an 
URL r^resented by the underline portion of tiie record. The individual records are Umited to 
the attorney usa-, and do not include other attorneys billing on the related matter, as were 
pr^ented to the accountant on page 432c discussed above Thus the query elements 436 and 
442 of the associated .jsp page432j themselv^ result in a variation of the query to the 
database by the web and database servers 400-402, depending on the role of the requesting 
user. Additionally, an active element is assembled into the page. The active element in the 
page is the "new" button 468 vMch is assembled by the web server from input type element 
440 within the time-cost .jsp page 432j, in r^ponse to a determination that the requesting vs&r 
has a role of attorney in the registration table The selection of the new button 468 results in 
the display of time-cost input formhtm page 480a from the related time-cost-form jsp page 
discussed above. That form as assembled for the attorney include: form 484, active links 486 
and a submit/enter icon 490 which allows the usa- to add their new time or cost mtry to the 
database. Where the attomey selected an URL on an existing entry in the list a similar form 
480b is generated by the web server from the same time-cost input formjsp page discussed 
above (not shown). This time the form includes an update button 488 to allow the attomey to 
update the time or cost record in the database 

FIGS. 5A-C show various embodiments of software nK}dules and management 
tables for the professional practice appUcation of the current invaition. The application 
server 122 and storage 124 are shovwi to contain a web server 400 and a database server 
402. nie Web server couples via the Intemet 120 to the various users. The users make a 
request 450 and receive one or more responses 452 depending on the role of the user as 



recorded in the registration table 128. The Web server generally handles communications 
across the Intern^ and delivers data to the database server for recording in one of the 
associated tables 126-128. The application itself consists of one or more Web pages 134, 
access tables 130-132, registration table 128 , program code 500, and one or more data 
tables 126. The registration table 128 is accessible via the Web by those users whose role 
is listed as group manager. The registration table include group name, user id, password 
and role. A first of the access tables 130 correlates each web page 134 with the one or 
more roles in fields 520, 522 respectively. A second access table 132 correlates each table 
or objects structure in the database with one or more corresponding roles in fields 530-532 
respectively. The web page 432j discussed above in connection with FIG. 4 contains 
various static elements 438 as well as dynamic elements. The dynamic elements shown are 
element 434 vvfcich is a functicai call to the program code 500 to determine the associated 
role of the requesting user. The role of the user is determined fi-om a session table 504 
\N4iidi is a volatile structure maintained by tiie web server 400 for avoiding repetitive login 
by a MS&c as each new page is displayed. 

A cUent wdj browsa: and a web server maintain "what is called a stateless 
connection. Each time requ^t is nmde from a wd) browser to a web server a temporary 
connection is estabhsh between the browser and server. The only information maintained 
by the server is a session identifier \^Auch avoids the need for r^ubmitting usemame and 
password with each communication. Other than that the communication is stateless 
because afta- each request is satisfied the connection between the Web browser and Web 
server is dropped. Using the s^sion and registration tables the web server under the 
direction of program code 500 determmes each isers role. FIGS. 5 A-C show three 
embodiments for correlating roles witii web pages and the dynamic elemaits they may 
contain. Jn FIG. 5 A dynamic element 434 results in a function executed by the web server 
usii^ program code 500 firom 'wMch the usar role is detaroined from the session 
information and title information in the registration table. The next dynamic element 440 
includes an embedded fimction, e.g. 'If-Then-Else" or "Case" vMdi conditions the 
generation of the HTML element, e.g. an URL 554 on a specific role, i.e. Atty 552. If the 
requKtors role is Attorney the web brov»^er will generate the element and inject it into the 
HTML page delivered to the user. Otherwise the element will not be generated, substituting 
inst^d a blank space. The web server recognizes the dynamic elements by virtue of 
characters 550,570 vMch idmtify the string. The accKS controUor 502 contains the 



program code access tables and registration tabl^ vdiich collectively implement to logic to 
properly layoiit and present the page depending on the role of the user. The pages contain 
varying degrees of information related to the role(s) associated with thar dynamic 
elements. 

In tiie embodiment of the invention shown in FIG. 5B the dynamic elements of the 
page contain identifiers 542 wlrich correlate the page and tiie dement number in the page 
with the function 540 requesting the usq- role. ITris allows the role information for each 
page to be stored in the page access table 130 in fields 524 and 526, ratha- than hard coded 

onto each page. The function 556, "page 1 element 1" (PlEl) evaluates true if the role of 
the ^er in the registration table 128 correlates with the role for the element recorded in the 
access table 130 as determined by the access control 502 module, including the above 
mentioned program code 500, access tabl^ 130-132 and registration table 128 discussed 
above. 

In the embodiment shown in FIG. 5C the dynamic elements of the web page 
include functions 540-542 to get the role and group of the user by corrdating the sKsion 
information for the requesting user with the user information in the r^stration tables. The 
fijnction 544 evaluates to true if the role recorded, this time in the access table in fields 
520, 522, 524, 526, and 528 corresponds with the role of the requesting usei stored in the 
registration table. This embodiment of the invention if inplemented in conjunction with a 
web page accessible to managers viliich allows them to input data for their group into 
access table 130, allo\i^ the user with manager role in each group to define new roles for 
tiie applicatioiL 

FIG. 6 is a process flow diagram of the proc^ses im^lanented by the web sQ-ver 400 
shown in FIGS. 4-5 for managing the professional practice application. After initialization 
600 processing begins in decision block 602 with the detection of a communication fi-om a 
new, or existing user. Next indecision process 604 a determination is made as to whether a 
session has been estabUshed for that user. In the event the session has not been fiilly 
established control passes to decision process 606. 

In decision process 606 a determination is made as to whether the registration, 
management, or login icons have beai selected on the login page shown in FIG. 3B. If the 
registration icon has beai selected control passes to decision process 608 to determine if 
the requested user name and password are unique in Ihe registration table. If they are then 
control passes to process 612 in whidi the role of tiie nmnager is allocated to the newly 
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registered user along with their user name and password in the registration table. Control 
then passes to process 620 in vMdi the srasion is established for that user and password. 
Control then passes to process 650. 

If alternately a determination is made in decision process 606 a d^ermination is 
made that a login icon has been selected then control asses to decision process 610 to 
determine if the user name and password combination exists in the r^stration table. If it 
does control passes to process 614 in \s*ich the us& role is looked up in the registration 
table. Control then passes to process 620 in which Ae session is established for that user 
and password. Control then passes to process 650. 

If alternately in decision process 606 a determination is nmdethat the icon selected on 
the login page is the manager icon then control p^ses to decision process 630. In decision 
process 630 a determination is made as to tiie role of the requesting user as recorded in the 
registration table. If they are listed as manager then control passes to decision process 632 in 
vMdi they are presented the managerial web page shown in FIG. 3D. Their action is 
evaluated to deternrine if it is an update^delete or an add. If their action is an update or delete 
control is passed to decision proems 640. In decision process 640 a determination is made as 
to whetho: their action would result in no user with role of manager for Aeir group, in \^^lich 
case the action is denied. Otherwise, control passes to proems 642 in wliich their update is 
performed subject to t^ts for uniqueness of the user name and password discussed above. 
Control then passes to process 620 in vMch the session is established for that user and 
password. Control then passes to process 650. 

If alternately in decision process 632 they desire to add a uso: control passes to process 
636 in >A4iich the user is added subject to tests for uniqueness of the user name and password 
discussed above. Control then passes to process 620 in vMch the session is established for that 
user and password. Control then passes to process 650. 

Once a session is established as determined in decision process 604 control passes to 
process 650 in vMch the user ID, group ED, and role is determined from the registration table. 
Control then passes to process 660 in vMch the nature of the user request, e.g. page request 
and OT database I/O is determined. Next in process 662 the role of the requested page and or 
data base I/O is determined from the relevant access table(s) 130-132 for tiie requested page or 
table. This is then con5>ared in process 664 with tiie role of the requesting user as recorded in 
the r^stration table and determined in process 650 discussed above. If the roles for Ifae 
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requesting user and flie requested page/data I/O match thm control passes to process 668. In 
process 668 Ihe rdevant assembly of page and/or database I/O is performed subsequent to 
wiiich control returns to decision process 602. 

The invention may be implemented on traditional server architectures. One 

embodiment of the invention its in^lemoited as a software module vMdi may be executed 

on a computer system in a conventional manner. Using well-known techniques, the 

software of this ranbodiment stored on the data storage medium 124 is loaded into and 

executed within server 122. 

The foregoing description of a preferred embodiment of the invention has been 
presented for purposes of illustration and description. It is not intaided to be exhaustive or to 
limit the invention to Ihe precise forms disclosed. Obviously many modifications and 
variations will be apparent to practitioners skilled in this art. It is intended that the scope of 
the invQition be defined by the following dain^i and their equivalaits. 
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